IBIS Macromodel Task Group

Meeting date: 14 August 2018

Members (asterisk for those attending):
ANSYS:                        Dan Dvorscak
                              Curtis Clark
Cadence Design Systems:     * Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                              Ken Willis
eASIC:                        David Banas
GlobalFoundries:              Steve Parker
IBM                           Luis Armenta
                              Trevor Timpane
Intel:                      * Michael Mirmak
Keysight Technologies:      * Fangyi Rao
                            * Radek Biernacki
                            * Ming Yan
                            * Stephen Slater
Mentor, A Siemens Business:   John Angulo
                            * Arpad Muranyi
Micron Technology:            Randy Wolff
                            * Justin Butterfield
SiSoft:                       Walter Katz
                              Todd Westerhoff
                            * Mike LaBonte
SPISim:                     * Wei-hsing Huang
Synopsys:                     Rita Horner
                              Kevin Li
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:             * Bob Ross

The meeting was led by Arpad Muranyi.  Justin Butterfield took the minutes.

--------------------------------------------------------------------------------
Opens:

- None

-------------
Review of ARs:

- Fangyi to draft a list of AMI issues that could be addressed by an AMI
  footprint change.
  - Fangyi reported he has prepared some slides on this.
  
- Randy to investigate if/why/how a clock waveform input might be used in
  IBIS-AMI.
  - Justin reported that discussions have started, but nothing there is nothing
    to share yet.
 
- Michael M. to investigate if/why/how a clock waveform input might be used in
  IBIS-AMI.
  - Michael reported that they are internally compiling and looking at a list
    of issues in including this.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the August 7
meeting.  Mike L. moved to approve the minutes.  Michael M. seconded the motion.
There were no objections.

--------------
New Discussion:

Modeling for Memory channels:
Fangyi shared slides titled "Modeling and Simulation Interface for Memory
Channels".  He commented that we had discussed modifying the footprint of the
AMI functions in the last meeting.  For the AMI Init function, the rise and
fall responses needs to be addressed.  The model Init function could return the
Tx equalization directly.  For Rx, the output could be a linear equalizer and
DFE.  We would not need crosstalk in the Init Tx DLL.  The Rx DLL is expected
to determine the Vref for the DFE slicer.

Fangyi noted some questions we need to address.  Vref is shared across a byte
lane.  He asked how can we model this or if it can it be neglected.  He
commented that Vref is determined by the controller and asked if we need to
handle this.  He noted the need to handle the common mode DC bias.  This needs
to be passed to the Rx, but he asked how does this work when you have a Tx EQ.
There is no clear definition how the Tx EQ impacts the DC common mode, unless
it is in the form of an FIR filter.  We may need restrictions on the Tx
output.  He asked how would the Rx DFE align with the step response.  He noted
there were some ideas to split Init into different functions for memory.

Fangyi noted for the AMI GetWave function we would need to input the clock
waveform, so the DFE knows how to derive the proper clock timing.  He asked if
we need a different GetWave signature for DQ, DQS, and CA.  Fangyi noted DQ is
single-ended, while DQS is differential.  He asked if we need different
definitions of GetWave for DQ and DQS and if we need different stimulus for the
different signal types.  He commented we need to clarify the Tx GetWave and
mentioned SiSoft and Cadence have proposed proprietary solutions can handle
this.  But, for a non-linear system you have to use certain techniques.  He
wondered if Tx GetWave can be eliminated and noted this would make the problem
much easier.  Most SERDES do not use Tx GetWave.  He noted that this may not be
a comprehensive list of the issues.

Fangyi considered a component centric model which would handle all DQ, DQS, CA
and CLK signals in a single DLL.  There would be no need for a reference, and
the model has all the information it needs.  Vref sharing would be naturally
handled inside the DLL.  But, this would increase the complexity.  He stated
this could also force the user to simulate everything even if they are only
interested in a few signals.  Arpad asked if it would have to be every signal,
or if it could be broken up.  Fangyi replied that it could be subdivided, and
this could be attractive.

Ambrish asked if the AMI GetWave model needs to behave differently for rising
and falling edges.  Fangyi stated only the analog portion of the model will be
different.  Ambrish thought only the data needs to be input to the DLL.  Fangyi
agreed and stated that he would input two impulse responses.  Ambrish asked if
this can be handled in the EDA domain.  Fangyi stated the EDA tool can handle
this.

Ambrish noted that he does use Tx GetWave, and he does not think we can
eliminate Tx GetWave.  Fangyi stated that we will need to address this problem
then.

Mike asked about the alignment for GetWave and if this is a clocking issue.
Fangyi replied yes, it is.  Mike thought the model would need to change to
address this.  Fangyi agreed and noted this would be used for the DFE timing.

Fangyi asked if we want something beyond AMI and if we want to combine things
into a Component Centric model.  Mike thought the essentials for this are the
same as they were for AMI.  He asked if it is essential to have both
statistical and time domain.  Fangyi stated this is a good question.

Arpad stated it sounds like we are thinking about something beyond AMI and
asked Fangyi if he had any thoughts what this would look like.  Fangyi replied
that the Component Centric model was one example.  

Michael asked what Fangyi means by AMI framework, and how the AMI flows would
need to change.  He asked if we believe an AMI approach to DDR is inaccurate.
Fangyi thought that it is an approximation, but it is still a useful approach.
Arpad asked if we think this is possible.  Ambrish stated that we are getting
closer to the LTI approach, and we must think about how to handle this in the
current framework.   

Arpad asked Ambrish how many of the changes he thinks would be necessary.
Ambrish agreed about the DQS timing and Vref as necessary.  He thought that
these can be handled in the model or by the tool.  Arpad asked if we did write
a BIRD to address these if he would agree with it.  Ambrish commented that we
should take a minimalist approach to the changes.  Arpad stated that we would
try to separate the topics into different BIRDs as necessary.  Ambrish thought
that we could reach some agreement.

Arpad asked what our next steps should be and asked if we should identify some
of the most pressing issues.  Stephen suggested to do a straw poll to sort the
list.  Fangyi thought that there are still a lot of questions.  Arpad asked how
many of the questions are necessary.  Fangyi replied that all of the questions
he listed are necessary to answer.  Arpad stated he hoped to narrow down the
scope of the BIRD with these slides.  Stephen asked if we should do this
offline.  Arpad thought we could entertain a motion.  Fangyi stated in his
opinion it is more efficient to discuss these questions in the meeting.

Ambrish commented the most important things to discuss are the ones he
mentioned earlier.  Arpad asked if we can decide how to approach the issues
next time.

- Bob: Motion to adjourn.
- Ambrish: Second.
- Arpad: Thank you all for joining.


-------------
Next meeting: 21 August 2018 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
